Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/osix400/osix400-minutes-90july.txt

Text File | 1993-02-17 | 10KB | 265 lines

CURRENT_MEETING_REPORT_



Reported by Robert Hagens/University of Wisconsin

OSI X.400 Minutes

Agenda


   o Review of the Draft Proposal for the use of the Internet DNS to
     maintain RFC 987/RFC 1148 Address Mapping Tables.
   o Discussion of the structure of O/R Addresses used by the Wisconsin
     Pilot X.400 project.
   o Address mechanisms that allow non-X.400 users (i.e., RFC 822 mail
     users) to address X.400 users.


The meeting was convened by Chair Robert Hagens.  An attendance list
will be published with the Proceedings of the IETF. The meeting had
several attendees from the NIST/OSI workshop, X.400 SIG.

A proposal has been circulated on several mailing lists; ``Draft
Proposal for the use of the Internet DNS to maintain RFC 987/RFC 1148
Address Mapping Tables'' (by Cole and Hagens) which describes how the
DNS could be used to store, retrieve, and maintain the mappings between
RFC 822 domain names and X.400 O/R addresses.

Implementations of RFC987 gateways require that a database store address
mapping informAtion for X.400 and RFC822.  This information must be
disseminated to all RFC987 gateways.  In the internet community, the DNS
has proven to be a practical means for providing a distributed
nameservice.  Advantages of using a DNS based system over a table based
approach for mapping between O/R addresses and domain names are:

  1. It avoids fetching and storing of entire mapping tables by every
     host that wishes to implement RFC987.
  2. Modifications to the DNS based mapping information can be made
     available in a more timely manner than with a table driven
     approach.
  3. Table management not necessarily required for DNS sites.
  4. One can determine the mappings in use by a remote gateway by
     querying the DNS (remote debugging).

The proposal was discussed.  A scenario was presented which demonstrated
an example lookup:

Given O/R Address:
      ``/c=us/admd= /prmd=nren/o=uw-madison/ou=cs/ou=dip/s=hagens''

and DNS record

                                   1






      ``*.cs.uw-madison.nren.  .us.x400'' IN TO-822 6 cs.wisc.edu


  1. O/R Address is rewritten as a domain name with attribute values
     used as domain components:  dip.cs.uw-madison.nren.  .us
  2. Lookup domain name within X.400 top-level domain:
     lookup(dip.cs.uw-madison.nren.  .us.x400)
     returns cs.wisc.edu (count = 6)
  3. Since the count indicates that only 6 of the 7 attributes were
     matched, any unmatched components must be prepended.  In this case,
     prepend ``dip''.
  4. Result:  dip.cs.wisc.edu


The proposal received general acceptance.  Several changes to the
approach have been suggested which differ from that specified in the
proposal.  These changes are summarized below:


  1. DNS representation of O/R address to use O/R attribute values
     directly, not appendix F notation.
  2. The new tree of X.400->RFC 822 resource records should be placed
     within a new top level domain (the name of this top level domain is
     undecided).
  3. Generation of table information from DNS is performed via recursive
     zone transfers of the x.400 tree (instead of an automated submittal
     process).  This is probably the biggest issue to be resolved.  It
     is vital that the process of extracting the mappings from the DNS
     be given a thorough analysis so as to insure that it is feasible.
  4. Wildcard count field can be changed so that it is statically
     entered in authoritative input data, instead of computed by
     authoritative servers.
  5. Discard preference field in proposed resource records.


A portion of the X.400 session was spent discussing X.400 naming and in
particular the construction of RFC822 addresses to reach users who are
really using X.400.  This discussion was led by Allan Cargille,
University of Wisconsin

I. Naming Choices.
When determining initial X.400 O/R Names, one can either derive the new
X.400 names from existing RFC822 addresses, or can start afresh with new
names that take advantage of the semantics of the O/R Name structure.
In particular, one can select X.400 Organization and Organizational Unit
names that are more suitable for database lookup.  For example, at the
University of Wisconsin-Madison, they have existing addresses of the
form [e-mail].  Constructing the X.400 O/R Name from the
existing RFC822 name could yield something like:

      c=us; admd= ; prmd=xnren; o=wisc+edu; ou=cs; s=user



                                   2






while starting afresh could yield names like:

      c=us; admd= ; prmd=xnren; o=uw-madison; ou=cs; s=user

So far in the NSF X.400 project they have taken the second approach,
that of constructing new O/R Names instead of deriving them from
existing domain names.

Group opinion was that sites should have the freedom to select whatever
O/R Name they felt would be most helpful, either derived from an
existing domain name, or newly selected.

II. Addressing X.400 Users From The RFC822 World.
There are several approaches that can be taken.  All have technical
advantages and disadvantages -- it is not obvious that any choice would
be ``right'' or ``wrong''.  Assume that there are people in the U.S.
Internet that are using X.400 as their email service.  Users in the
RFC822 world need to be able to address these X.400 users.  It is
assumed that part of the user population at a site may move to X.400,
while the remainder of the users continue to use RFC822 mail.

A. Default solution as per RFC987.  Mail would be explicitly sent to an
RFC987 gateway, with the X.400 address on the left hand side of the
``@'' and the gateway address on the right hand side.  This would look
like

      ``c=us;admd=
;prmd=xnren;o=uw-madison;ou=cs;s=user''@x400.gateway.us.

This scheme does not require any special mapping records in the RFC987
gateway.

B. RFC987 Regular Mapping Rule.  This solution has been adopted by some
European countries.  The RFC822 address for an X.400 user is composed by
using concatenating values of the X.400 address.  For example, a user
with the X.400 address

       c=us;admd= ;prmd=xnren;o=uw-madison;ou=cs;s=user

would be addressed as ``[e-mail]'' (or something
similar).  This looks much like an existing Internet address.  One would
also register MX records to direct mail for xnren.us or
organization.xnren.us to an RFC987 gateway.

One complication of this scheme is that it requires a REGULAR rule for
constructing the RFC822-style address from the X.400 address.  This
could be problematic in the U.S. in large.  For example, some government
sites will be using a value in the ADMD field, whereas other sites will
only use a blank in that field.

This scheme requires placing records in the global RFC987 mapping tables

                                   3






but only a few, because general mapping rules are being used.

This scheme creates a new address space inside the U.S. Internet in
parallel to existing addresses.

For a user who switched from RFC822 to X.400, mail to the that user's
``old'' Internet address would still work due to the use of a system
alias or .forward file to forward the mail to the new address (and thus
to the RFC987 gateway).

C. Mapping to Existing Names.  This solution would keep the names used
to reach X.400 users consistent with the existing domain names.  Each
site would register a local MX record in their existing domain name
space that points to an RFC987 gateway.  This would look very much like
just another hostname.  Mail to the X.400 users would be sent to this
new MX record and be forwarded to a gateway.  For example, in the
University of Wisconsin Computer Science Department, addresses look like
[e-mail].  Several people are starting to use X.400, and RFC822
mail was directed to them as:

      [e-mail], or       [e-mail]

This scheme requires entering a mapping record for every organization
into the global RFC987 mapping tables.

Discussion.  The Working Group recommended solution C above because it
is most consistent with existing domain names, and does not require the
creation of any new high-level domains.  The Working Group expressed
concern at the ``x400'' string being used as part of a user address
(even though this is really just part of an MX record name) because in
general we do not want to encourage people to externalize the kind of
email end-system inside the email address.  Based on this input, the
Wisconsin NSF X.400 project has changed to Internet-style addresses of
the form:

      [e-mail], or       [e-mail]

Action Items:

Prepare a new version of the DNS proposal.  Complete by next IETF
meeting.

Attendees


Dave Borman              [e-mail]
David Brent              [e-mail]
C. Allan Cargille        [e-mail]
Isaac Chan               [e-mail]
Andrew Cherenson         [e-mail]
Richard Colella          [e-mail]

                                   4






Curtis Cox               [e-mail]
Mark Crispin             [e-mail]
Ella Gardner             [e-mail]
Martin Gross             [e-mail]
Robert Hagens            [e-mail]
Erik Huizer              [e-mail]
Jim Knowles              [e-mail]
Neil Koorland            [e-mail]
Walter Lazear            [e-mail]
Judy Messing             [e-mail]
Paul Mockapetris         [e-mail]
Jim Reinstedler          [e-mail]
Erik Skovgaard           [e-mail]
Einar Stefferud          EStefferud@ECL
Roxanne Streeter         [e-mail]
Peter Vanderbilt         [e-mail]
Chris Weider             [e-mail]
Linda Winkler            [e-mail]
Jean Wu                  [e-mail]



                                   5